home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000471_montulli@ukanaix.cc.ukans.edu _Wed Dec 9 20:52:07 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <montulli@ukanaix.cc.ukans.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA29545; Wed, 9 Dec 92 20:52:07 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA01984; Wed, 9 Dec 1992 21:05:31 +0100
  6. Received: by ukanaix.cc.ukans.edu (AIX 3.1/UCB 5.61/4.03)
  7.           id AA24547; Wed, 9 Dec 92 14:03:50 -0600
  8. From: montulli@ukanaix.cc.ukans.edu (Lou Montulli)
  9. Message-Id: <9212092003.AA24547@ukanaix.cc.ukans.edu>
  10. Subject: Re: Lynx
  11. To: timbl@nxoc01.cern.ch
  12. Date: Wed, 9 Dec 92 14:03:47 CST
  13. Cc: www-talk@nxoc01.cern.ch
  14. In-Reply-To: <9212090926.AA01030@www3.cern.ch>; from "Tim Berners-Lee" at Dec 9, 92 10:26 am
  15. X-Mailer: ELM [version 2.3 PL2]
  16.  
  17. > 
  18. > Lynx looks very nice -- but is it WWW?  From the comments about the syntax
  19. > it doesn't seem to be HTML.  It has Gopher access built in, but there is no  
  20. > access from KUfacts.cc.ukans.edu to the web.
  21.  
  22. No it is not WWW, but you are right that it should not be difficult to
  23. add html compatibility.  Maybe I'm wrong but it seems that the majority
  24. of the resources that I see available are in Gopher format.  Our 
  25. concentration has been more towards the user interface than the protocal.
  26. A fatal flaw perhaps?  Adding html will correct those problems because
  27. obviously a great deal of though has gone into its implementation.
  28. If we had know about WWW before beginning work on this project, chances
  29. are we would have used WWW and just rewritten the curses client to look
  30. halfway reasonable.
  31. > 
  32. > These guys have done some good work on hooking into existing services.
  33. >The emphasis seems to be on building in extra bits and peices(rexec, hytelnet, 
  34. > etc) into the browser rather than making gateways.  In the long run I think  
  35. > this approach will get too heavy on browsers. For hytelnet, for example, a
  36. > gateway is more efficient than building stuff very specific to one information  
  37. Hytelnet compatability was not added as an after thought.  The markup 
  38. language began compatible with hytelnet and evolved from there.  Our 
  39. focus in designing the language was to make it easily understood by
  40. non-programmers and I think we have achieved that, but this limits
  41. its functionality, again we are back to needing html.
  42.  
  43. >providing application into the browsers.
  44. > 
  45. >The screen management is neat. I wonder whether we could persuade them to make  
  46. >it W3 compatible?  (And their data with it?)  The user interface is quick and  
  47. >simple. I missed "home" and "back", "next" and "previous" commands of the www  
  48.  
  49. If you wish to retreat from a document you simply have to push the left arrow.
  50. The user controls were adopted from hytelnet, very simple and user freindly.
  51. Right arrow - follow a link
  52. Left arrow  - retreat form a link
  53. up arrow    - next link
  54. down arrow  - previous link
  55.  
  56. >line mode interface: one has always to go through the history page. But that  
  57. > keeps it simpler. I was glad I had more than 24 lines 9and the program  
  58. > recognised the fact) when the history list started to grow.
  59. > 
  60. > (Anyone want to make an W3 gateway for hytelnet?)
  61.  
  62. Will this gateway re-write the links inside hytelnet documents to match
  63. html?
  64.  
  65. > 
  66. > I am sure they could parse HTML with very little effort, and join the WWW club.
  67. > The existing text at KUfacts would all fit into the <PRE> format I think.
  68. > Their <!RLOGIN@library.host.edu -user=libcat> would be www's
  69. > <a href=rlogin://libcat@library.host.edu> I assume.(This is not very general  
  70. > of course as not all systems support rlogin).
  71.  
  72. Rlogin code can be included in the client for systems without native Rlogin.
  73. This is a very useful feature, is it unreasonable to include the code?
  74.  
  75. :lou
  76. -- 
  77.   **************************************************************************
  78.   *           T H E   U N I V E R S I T Y   O F   K A N S A S              *
  79.   *      Lou  MONTULLI @ Ukanvax.bitnet                Nothing difficult,  *
  80.   *                      Kuhub.cc.ukans.edu               is ever easy!    *
  81.   *  UNIX,               Ukanaix.cc.ukans.edu       ACS Computing Services *
  82.   *   have more fun!     Ukanvm.cc.ukans.edu           Lawrence, KS 66044  *
  83.   **************************************************************************